In the computer field, a program bug refers to a potential flaw and/or mistake in a computer program that may prevent the computer program from performing as intended. Generally speaking, program bugs may have a variety of impact. In an example, a program bug may cause minor annoyances such as sending an end-user to a defunct web page when the user clicks on a link. A program bug may also cause more serious problems, such as causing an application to freeze or create security flaws such as denial of service attack or system being taken over via buffer overruns and/or endless loops. Further, a program bug may enable a third party program to exploit flaws in the computer program to attack the software and/or hardware of a computer.
Generally, before a computer program may be moved into production, a code review process may be employed to identify program bugs in the computer program. In the prior art, the process of reviewing the code has been mostly a manual process. One method of reviewing the code is to manually review the source code; however, this method may require vast amount of resources, such as time and man-power. Further, the reviewer(s) may not necessarily have the necessary skill set and knowledge to adequately review the source code. Thus, manual code review is usually not an efficient method for performing an in-depth code review.
Another method that may be employed to review the source code may be to employ a scanning-based tool. Generally speaking, a scanning-based tool is a software application that employs an algorithmic approach to scan through the source code to identify potential problems. In an example, a scanning-based tool may scan through the source code looking for source tokens that may map to unsecured application program interface (API). API is well-known to those skilled in the art. Thus, no further discussion will be provided about API.
Although scanning-based tools may identify potential problems, these tools are usually not able to identify the sources of the problems. In an example, a scanning-based tool may be able to identify that line 20 has an error, but the tool may be unable to identify the originating source of the problem. As a result, the tedious task of identifying the originating source of the bug may still exist. Thus, the process of analyzing source code may still require extensive time and man-power that may not always be available, especially during time-crunch situations.
To facilitate discussion, FIG. 1 shows a simple logic diagram of a computer programming development cycle. During a design specification step 102, the requirements for a new computer program may be provided. At a next step 104, the design specification may be reviewed by the security review team to identify any potential program bug that may exist in the overall architecture of the design. At a next step 106, one or more programmers may begin the coding process using the design specification. Upon completing his programming, each programmer may review his source code for any potential problem, at a next step 108. This step may be a manual task that may require each programmer to check his code for potential problems. Since this is usually a labor intensive process, the computer program may not be sufficiently analyzed.
After each programmer has reviewed his code, the programmer may send his code to another programmer to perform peer review, at a next step 110. Besides being reviewed by another programmer, the code may be tested, at a next step 112. Examples of types of tests that may be performed include, but are not limited to, function testing and regression testing. In addition, at a next step 114, scanning-based tools may be employed to review the code for potential problems. Generally, the results from scanning-based tools may include a large amount of data; however, a large portion of these data may not be program bugs but still represent data that requires the programmer to review. As discussed earlier, the results from the scanning-based tools may lack sufficient information that can readily point out the source of the problem. Thus, at a next step 116, the programmers may still have to perform a labor intensive review of the results from the scanning-based tools.
At a next step 118, if program bugs are identified, then the programmers may fix the bug. Steps 108 through step 118 are iterative steps that may be repeated until no additional program bugs are identified. Once no more program bugs are identified, then at a next step 120, stress testing for finding security flaws may be performed. In stress testing, the testers may be performing extreme tests that are meant to severely stress the system. If program bugs are identified during stress testing, then at a next step 122, the program bugs may be fixed and steps 108 through steps 122 may be repeated until no additional program bugs are discovered. Once all program bugs are identified, then the computer program may be released and moved into production, at a next step 124.
As can be appreciated from the foregoing, the traditional computer program development cycle can be quite long and tedious. This is mostly due to the iterative steps 108 through 122, which may be fairly labor intensive. In a competitive market where first-to-market may be critical, a long development cycle is counterproductive.
Further, FIG. 1 shows that a high expertise level of knowledge may be required by the reviewers. Generally, a programmer may have strong knowledge on application development. However, the software field being complex and fast moving, it is difficult for a single person to know all the skill sets related to software development. Accordingly, it is not uncommon to find that many programmers, even skilled programmers who are experts in coding, do not possess detailed and up-to-date knowledge regarding computer security.
In addition, in the development of a large and complex application and particularly one developed in a compressed time frame (as commercial applications often are), individual programmers are assigned to only small portions of the overall project. Thus, it is typically the case that programmers working on a typical commercial software project do not have the overall knowledge of all modules of the project. As such, it is possible for skilled programmers to create modules and functions that are error-free when tested individually but result in program bugs when the individual modules and functions are integrated into the larger application program. As a result, computer programs may be moved into production with unidentified program bugs, creating an open window for potential hackers to create havoc to the system.